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Abstract.  Salsa  is  an  invariant  checker  for  specifications  in  SAL  (the 
SCR  Abstract  Language).  To  establish  a  formula  as  an  invariant  with¬ 
out  any  user  guidance  Salsa  carries  out  an  induction  proof  that  uti¬ 
lizes  tightly  integrated  decision  procedures,  currently  a  combination  of 
BDD  algorithms  and  a  constraint  solver  for  integer  linear  arithmetic,  for 
discharging  the  verification  conditions.  The  user  interface  of  Salsa  is  de¬ 
signed  to  mimic  the  interfaces  of  model  checkers;  i.e.,  given  a  formula  and 
a  system  description,  Salsa  either  establishes  the  formula  as  an  invariant 
of  the  system  (but  returns  no  proof)  or  provides  a  counterexample.  In 
either  case,  the  algorithm  will  terminate.  Unlike  model  checkers,  Salsa 
returns  a  state  pair  as  a  counterexample  and  not  an  execution  sequence. 
Also,  due  to  the  incompleteness  of  induction,  users  must  validate  the 
counterexamples.  The  use  of  induction  enables  Salsa  to  combat  the  state 
explosion  problem  that  plagues  model  checkers  -  it  can  handle  specifica¬ 
tions  whose  state  spaces  are  too  large  for  model  checkers  to  analyze.  Also, 
unlike  general  purpose  theorem  provers,  Salsa  concentrates  on  a  single 
task  and  gains  efficiency  by  employing  a  set  of  optimized  heuristics. 


1  Introduction 

Model  checking[17]  has  emerged  as  an  effective  technique  for  the  automated 
analysis  of  descriptions  of  hardware  and  protocols.  To  analyze  software  system 
descriptions,  however,  a  direct  application  of  model  checking  to  a  problem  (i.e., 
without  a  prior  reduction  of  its  state  space  size  by  the  application  of  abstraction) 
rarely  succeeds  [9].  For  such  systems,  theorem  proving  affords  an  interesting  al¬ 
ternative.  Conventional  theorem  proving  systems,  however,  are  often  too  general 
or  too  expensive  to  use  in  a  practical  setting  because  they  require  considerable 
user  sophistication,  human  effort,  and  system  resources.  Additionally,  the  coun¬ 
terexample  provided  by  a  model  checker  when  a  check  fails  serves  practitioners 
as  a  valuable  debugging  aid.  However,  in  contrast,  conventional  theorem  provers 
provide  little  or  no  diagnostic  information  (or  worse,  may  not  terminate)  when 
a  theorem  is  not  true. 
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Salsa  is  an  invariant  checker  for  system  descriptions  written  in  a  language 
based  on  the  tabular  notation  of  SCR  [24]  called  SAL  (the  SCR  Abstract 
Language).  Given  a  logical  formula  and  a  system  description  in  SAL,  Salsa  uses 
induction  to  determine  whether  the  formula  is  true  in  all  states  (or  transitions) 
the  system  may  reach.  Unlike  concurrent  algorithms  or  protocol  descriptions, 
on  which  model  checkers  are  very  effective,  practical  SAL  models  usually  do 
not  contain  interleaving  concurrency  and  are  more  easily  amenable  to  induction 
proofs.  If  a  proof  fails,  Salsa  provides  a  counterexample.  Unlike  model  checkers, 
however,  the  returned  counterexample  is  a  state  or  a  state  pair  and  not  an  execu¬ 
tion  sequence.  Also,  due  to  the  incompleteness  of  induction,  users  must  validate 
a  returned  counterexample.  Salsa  has  the  attributes  of  both  a  model  checker 
and  a  theorem  proven  It  is  automatic  and  provides  counterexamples  just  like  a 
model  checker.  Like  a  theorem  prover,  it  uses  decision  procedures,  can  handle 
infinite  state  systems,  and  can  use  auxiliary  lemmas  to  complete  an  analysis. 

The  design  of  Salsa  was  motivated  by  the  need  within  the  SCR  Toolset  [23] 
for  more  automation  during  consistency  checking  [24]  and  invariant  checking  [9, 
22],  Salsa  achieves  complete  automation  of  proofs  by  its  reliance  on  decision 
procedures ,  i.e.,  algorithms  that  establish  the  logical  truth  or  falsity  of  formu¬ 
lae  of  decidable  sub-theories,  such  as  the  fragment  of  arithmetic  involving  only 
integer  linear  constraints  called  Presburger  arithmetic.  Salsa’s  invariant  checker 
consists  of  a  tightly  integrated  set  of  decision  procedures,  each  optimized  to  work 
within  a  particular  domain.  Currently,  Salsa  implements  decision  procedures  for 
propositional  logic,  the  theory  of  unordered  enumerations,  and  integer  linear 
arithmetic. 

Although  they  are  capable  of  checking  more  general  properties  (such  as  live¬ 
ness),  in  practice  model  checkers  are  most  often  used  to  check  invariant  proper¬ 
ties.  The  advantage  of  using  Salsa  over  a  standard  model  checker  for  this  task 
is  that  Salsa  can  handle  large  (even  infinite  state)  specifications  that  current 
day  model  checkers  cannot  analyze.  This  is  due  to  the  use  of  induction  and  the 
symbolic  encoding  of  expressions  involving  integers  as  linear  constraints.  The 
primary  disadvantage  of  Salsa  (and  proof  by  induction  in  general)  is  its  incom¬ 
pleteness  -  a  failed  check  does  not  necessarily  imply  that  a  formula  is  not  an 
invariant  because  the  returned  state  pair  may  not  be  reachable. 

After  some  experimentation,  we  arrived  at  the  following  practical  method  for 
checking  state  and  transition  invariants  using  Salsa  (see  Figure  1):  Initially  apply 
Salsa.  If  Salsa  returns  yes  then  the  property  is  an  invariant  of  the  system,  and  we 
are  done.  If  Salsa  returns  no,  then  we  examine  the  counterexample  to  determine 
whether  the  states  corresponding  to  the  counterexample  are  reachable  in  the 
system.  If  so,  the  property  is  false  and  we  are  done.  However,  if  one  concludes 
after  this  analysis  that  the  counterexample  states  are  unreachable,  then  one  looks 
for  stronger  invariants  to  prove  the  property.  Salsa  currently  includes  a  facility 
that  allows  users  to  include  such  auxiliary  lemmas  during  invariant  checking. 
There  are  promising  algorithms  for  automatically  deducing  such  invariants  [5,6, 
11,26],  although  Salsa  currently  does  not  implement  them. 
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Fig.  l.  Process  for  applying  Salsa. 


Related  Work.  The  use  of  SMV  [28]  and  SPIN  [25]  on  software  specifications  for 
consistency  and  invariant  checking  has  been  well  documented  [2,  9, 16, 22].  SCR* 
[23]  is  a  toolset  that  includes  a  consistency  checker  which  uses  a  method  based 
on  semantic  tableaux  extended  to  handle  simple  constraints  over  the  integers 
and  reals.  This  tool  has  proved  very  useful  in  a  number  of  practical  case  studies; 
however,  the  tool  is  unable  to  complete  the  checks  on  certain  examples  involving 
numbers.  Systems  that  largely  automate  induction  proofs  by  employing  decision 
procedures  include  the  Stanford  Temporal  Prover  (STeP)  [11].  Other  tools  that 
are  built  upon  the  interactive  theorem  prover  PVS  [30]  include  TAME  (Timed 
Automata  Modeling  Environment)  [3]  and  the  tools  of  Graf  et  al.  [21,32],  These 
tools  are  implemented  as  a  set  of  special-purpose  PVS  strategies.  The  tool  In- 
VeSt  includes  sophisticated  algorithms  for  invariant  generation  and  heuristics  for 
invariant  strengthening  [5, 6].  Also,  if  invariance  cannot  be  established  on  a  finite 
abstraction,  an  execution  sequence  is  provided  as  a  diagnostic.  Validity  checkers 
such  as  Mona  [18],  Mosel  [31],  and  the  Stanford  Validity  Checker  (SVC)  [4]  are 
another  class  of  systems  that  employ  decision  procedures  for  proving  logical  for¬ 
mulae.  Although  these  tools  do  not  directly  check  invariants,  they  may  be  used 
to  discharge  the  verification  conditions  generated  during  an  induction  proof  in 
a  tool  such  as  Salsa. 

The  idea  of  combining  decision  procedures  for  program  verification  dates 
back  to  the  work  of  Shostak  [33]  and  Nelson  and  Oppen  [29].  The  decision  pro¬ 
cedures  of  Salsa  for  both  propositional  logic  and  enumerated  types  are  based  on 
standard  BDD  algorithms.  The  integer  constraint  solver  employs  an  automata- 
theoretic  algorithm  presented  in  [12],  with  extensions  to  handle  negative  numbers 
using  ideas  from  [34],  Salsa’s  technique  of  combining  BDD  algorithms  with  con¬ 
straint  solvers  was  largely  inspired  by  the  approaches  of  [14]  and  [15]  where, 
by  incorporating  constraint  solvers  into  BDD-based  fixpoint  computation  algo¬ 
rithms,  verification  of  infinite  state  systems  becomes  a  possibility.  However,  since 
the  underlying  algorithms  of  these  systems  are  variants  of  the  model  checking 
algorithm  for  computing  a  fixpoint,  we  speculate  that  Salsa,  due  to  its  use  of  in¬ 
duction,  can  handle  larger  specifications  than  these  systems.  Also,  the  constraint 
solver  of  [14]  is  incomplete  for  integer  linear  arithmetic,  whereas  the  one  used  by 
Salsa  is  complete.  The  system  of  [15],  which  uses  an  off-the-shelf  backtracking 
solver  that  can  be  very  inefficient  in  practice,  can  handle  a  class  of  non-linear 
constraints  in  addition  to  linear  constraints. 
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The  rest  of  this  paper  is  organized  as  follows.  In  the  following  section  we 
introduce  the  state  machines  that  serve  as  the  underlying  models  for  SAL  speci¬ 
fications  and  define  the  invariant  checking  problem.  Section  3  describes  the  core 
algorithms  of  Salsa,  and  Section  4  presents  the  algorithms  and  heuristics  of  the 
unsatisfiability  checker  which  is  used  by  Salsa  to  discharge  the  verification  condi¬ 
tions.  Section  5  provides  some  preliminary  experimental  results  of  applying  Salsa 
to  several  practical  specifications  of  moderate  size.  Finally,  Section  6  discusses 
ongoing  work  and  future  research. 

2  Background 

2.1  Model  for  System  Behavior 

The  SCR  Abstract  Language  (SAL),  a  specification  language  based  on  the  SCR 
Formal  Model  [24],  was  designed  to  serve  as  an  abstract  interface  to  analysis 
tools  such  as  theorem  provers,  model  checkers,  and  consistency  checkers.  An 
example  SCR  specification  in  SAL  is  presented  in  Appendix  A.  Unlike  concur¬ 
rent  algorithms  or  protocol  descriptions,  practical  SAL  specifications  usually  do 
not  involve  interleaving  concurrency  and  are  therefore  more  easily  amenable  to 
induction  proofs. 

A  SAL  specification  may  be  translated  into  a  state  machine  that  models  a 
system’s  behavior.  We  now  introduce  the  state  machine  model  for  systems  and 
the  supporting  machinery  used  in  the  paper.  We  define  formulae  in  a  simple 
constraint  logic  (SCL)  by  the  following  grammar: 

$  :=  C  |  Xb  |  -i A 'b  |  $  V  $  |  $  A  <P  (simple  formulae) 

C  :=  Ci  |  Ce  (constraints) 

Ce  :=  Xe  =  Vale  |  Xe  ^  Vale  \  Xe  =  Ye  \  Xe  ^  Ye  (enum.  constraints) 

Ci  :=  SUM  <  Vali  \  SUM  =  V alt  \  SUM  ^  Vali  (integer  constraints) 
SUM  —ValiX  Xi  |  SUM  +  SUM 

where  Xb,  Xe/Ye,  and  Xj  range  over  boolean,  enumerated,  and  integer  variables 
respectively.  Similarly  Valb,Vale,  and  Vali  respectively  range  over  constants  of 
the  three  types.  We  let  Vars{$)  denote  the  free  variables  in  <P.  Set  Vars{$) 
is  partitioned  by  the  three  variable  types:  Vars{$)  =  Varsb ($)  U  Varse($)  U 
l  '«/•*,  (</').  Note  that  SCL  formulae  will  be  interpreted  in  the  context  of  either  1) 
a  single  state  s  that  maps  variable  names  to  values  or  2)  a  pair  of  states  (s,s'), 
where  s'  is  a  successor  of  s.  We  adopt  the  convention  that  primed  formulae  and 
variable  names  (those  ending  in  ')  are  evaluated  in  the  “new  state”  whereas 
unprimed  names  are  evaluated  in  the  “old  state.”  Formulae  containing  primed 
variables  are  called  two-state  predicates  and  those  without  primed  variables  are 
called  one-state  predicates. 

Definition  1.  A  state  machine  A  is  a  quadruple  ( V,S,0,p )  where 

—  V  is  a  set  of  variable  names.  This  set  is  partitioned  into  monitored  variables 
which  denote  environmental  quantities  the  system  observes;  controlled  vari¬ 
ables  which  denote  quantities  in  the  environment  that  the  system  controls; 
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and  internal  variables  which  are  updated  by  the  system  but  not  visible  to 
the  environment. 

—  S  is  the  set  of  system  states  such  that  each  state  s  G  S  maps  each  x  G  V 
to  a  value  in  its  set  of  legal  values.  We  write  x(s)  to  mean  the  value  of 
variable  x  in  state  s,  &i(s)  to  mean  the  value  of  one-state  predicate  V>\ 
evaluated  in  s,  and  #o  (s,s')  to  mean  the  value  of  two-state  predicate  @2 
evaluated  with  values  from  s  replacing  unprimed  variables  and  values  from 
s'  replacing  primed  variables. 

—  9  is  a  one-state  SCL  predicate  defining  the  set  of  initial  states. 

—  p  is  a  two-state  SCL  predicate  defining  the  transitions  (execution  steps)  of 
E.  A  state  s  may  evolve  to  a  state  s'  if  p(s,  s')  is  true. 

The  transition  relation  p  additionally  includes  environmental  assumptions 
as  well  as  assumptions  introduced  by  users.  For  details,  see  [10]. 


2.2  The  Invariant  Checking  Problem 

Definition  2.  Given  a  state  machine  E  =  (V,S,9,p),  a  state  s  G  S  is  reachable 
(denoted  Reachable  r(s))  if  and  only  if  0(s)  or  3s2  G  S  :  Reachablez(so)/\p(s-2,  s) 

Definition  3.  Given  a  state  machine  E  =  (V,  S,  9,p),  a  one-state  SCL  predicate 
is  a  state  invariant  of  E  if  and  only  if 

Vs  G  S  :  Reachables(s )  =>  $i(s) 

A  two-state  SCL  predicate  #2  is  a  transition  invariant  of  E  if  and  only  if 
Vs,  s'  G  S  :  (Reachable z(s)  A  p(s,  s'))  =>-  ^(S"^) 

The  invariant  checking  problem  :  Given  a  state  machine  E  and  a  one(two)-state 
predicate  <!>.  determine  whether  $  is  a  state(transition)  invariant. 


3  The  Invariant  Checker 

Theorem  1.  Let  E  =  (V,  S,  6,  p),  then  is  a  state  invariant  of  E  if  the  follow¬ 
ing  hold:  1)  Vs  G  S  :  6(s)  =>  T>\  (s)  and  2)  Vs,  s'  G  S  :  $i(s)  A  p(s,s')  =>  T>\  (s') 

Proof:  By  induction  on  the  number  of  steps  of  E  to  reach  a  state. 

Theorem  2.  Let  E  =  ( V,S,9,p ),  then  $2  is  a  transition  invariant  of  E  if  the 
following  holds: 

Vs,  s'  G  S  :  p(s,  s')  =>  $2(s,  s') 

Proof:  Follows  directly  from  Definition  3. 
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3.1  The  Invariant  Checking  Algorithms 

Using  Theorems  1  and  2  we  check  invariants  of  A  =  ( V,S,6,p )  as  follows: 

State  Invariants.  To  determine  if  is  a  state  invariant  of  A: 

0.  if  -i<?i  is  unsatisfiable  then  return  yes. 

1.  if  6  A  -i$i  is  not  unsatisfiable  then  return  no  and  the  satisfying  state  as 
counterexample . 

2.  if  A  p  A  -i^'j  is  unsatisfiable  then  return  yes. 

else  return  no  and  the  satisfying  state  pair  as  counterexample. 

Transition  Invariants.  To  determine  if  is  a  transition  invariant  of  A: 

0.  if  -i#2  is  unsatisfiable  then  return  yes. 

1.  if  p  A  — 1$2  is  unsatisfiable  then  return  yes. 

else  return  no  and  the  satisfying  state  pair  as  counterexample. 

These  algorithms  are  sound  but  not  complete  -  whenever  Salsa  returns  yes 
the  given  formula  is  an  invariant;  however,  a  no  answer  with  a  counterexample  (a 
state  or  a  state  pair)  does  not  necessarily  mean  that  the  formula  is  not  an  invari¬ 
ant.  Consequently,  the  user  must  validate  that  the  counterexample  is  reachable1. 
Either  there  is  a  problem  or  additional  theorems  are  used  to  “push  through”  the 
invariant.  Of  course,  all  added  theorems  should  be  proved  as  invariants  by  the 
user  (either  with  Salsa  or  by  some  other  means). 

3.2  Optimizations 

A  naive  application  of  the  above  algorithms  to  invariant  checking  will  always 
fail,  even  for  specifications  of  a  moderate  size.  We  perform  several  optimizations 
in  Salsa  to  make  invariant  checking  feasible.  One  important  technique  used  ex¬ 
tensively  is  to  cache  results  as  they  are  computed.  In  addition  to  the  caching 
provided  by  BDD  algorithms,  we  cache  the  results  of  calls  to  the  integer  con¬ 
straint  solver,  the  BDD  encodings  of  components  of  the  transition  relation,  etc. 

To  partition  an  unsatisfiability  check  into  simpler  sub-problems,  we  use  a 
technique  called  disjunctive  partitioning  which  corresponds  to  a  case  split  in  a 
standard  proof.  This  approach  takes  advantage  of  the  fact  that  a  disjunction  is 
unsatisfiable  only  if  each  of  its  disjuncts  is  unsatisfiable.  The  disjunctive  form  of 
the  transition  relation  in  SAL  specifications  has  proven  to  be  an  effective  basis 
for  disjunctive  partitioning. 

The  application  of  abstraction  [9,22]  is  also  very  beneficial.  We  restrict  our¬ 
selves  to  applying  abstractions  that  are  both  sound  and  complete,  by  which  we 
mean  the  following.  Given  a  property  and  a  state  machine  A,  an  abstraction 
Sa  is  a  sound  and  complete  abstraction  of  A  relative  to  when  <P  is  an  invariant 
of  A 4  if  and  only  if  #  is  an  invariant  of  A.  Currently,  we  apply  what  is  termed 
“ Abstraction  Method  1 ”  [8,9]  that  uses  the  set  of  variable  names  occurring  in 
the  predicate  #  and  dataflow  analysis  to  eliminate  unneeded  variables. 

1  The  single  state  counterexample  returned  by  step  1  of  the  algorithm  for  State  Invari¬ 
ants  (for  a  failed  check  of  unsatisfiability  of  9  A~>d>i )  is  always  a  true  counterexample. 
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4  The  Unsatisfiability  Checker 


4.1  Overview 

To  discharge  the  verification  conditions  that  arise  during  invariant  checking, 
Salsa  uses  a  routine  that  decides  the  unsatisfiabilitv  of  SCL  formulae.  Both  the 
problem  of  propositional  unsatisfiability  and  the  decision  problem  for  integer 
linear  arithmetic  are  NP-complete  [20],  and  known  algorithms  for  the  latter 
problem  have  super-exponential  worst  case  behavior  [19].  The  unsatisfiability 
checker  uses  a  combination  of  binary  decision  diagrams  and  an  integer  constraint 
solver  as  a  decision  procedure  for  SCL  formulae.  Using  the  formula  x  <  4A;r  =  7 
as  an  example  we  outline  the  algorithm  (for  specifics,  see  [10]).  The  initial  step 
transforms  a  formula  into  one  containing  only  logical  connectives  and  boolean 
variables.  This  is  done  by  assigning  a  fresh  boolean  variable  to  each  integer 
constraint  in  the  original  formula.  Fresh  boolean  variables  are  also  introduced 
to  encode  expressions  involving  variables  of  enumerated  type  in  the  obvious  way 
[10,28].  For  the  example,  substituting  a  for  x  <  4  and  b  for  x  =  7  yields  the 
formula  a  A  b.  Next,  a  BDD  for  this  formula  (which  encodes  the  propositional 
structure  of  the  original  formula)  is  constructed: 

a 

/\ 

b 

//  \ 

False  True 

The  next  step  brings  in  the  information  contained  in  the  integer  constraints. 
This  is  done  by  searching  for  paths  from  the  root  to  “True” ,  each  path  yielding  a 
set  of  integer  constraints.  For  the  example,  the  only  path  from  the  root  to  “True” 
sets  both  a  and  b  to  true,  which  yields  the  set  {.t  <4,  x  =  7}.  The  final  step 
is  to  determine  whether  each  such  set  is  infeasible  (i.e. ,  has  no  solution)  using 
an  integer  constraint  solver.  If  a  set  is  feasible,  this  information  is  returned  to 
the  user  as  a  counterexample.  For  the  example,  the  (single)  set  of  constraints  is 
infeasible  and  the  formula  is  unsatisfiable.  We  now  describe  the  integer  constraint 
solver  in  detail. 


4.2  The  Integer  Constraint  Solver 

As  an  initial  step,  a  set  of  integer  constraints  is  partitioned  into  independent 
subsets.  For  example,  the  set  of  constraints  { x  <  4,  x  >  7,  y  <  10}  may  be  par¬ 
titioned  into  {;r  <  4,;r  >  7}  and  {y  <  10}. 


Definition  4.  Constraints  c\  and  Co  are  independents  Uars(ci)nUars(co)  =  0. 
The  partition  of  a  set  of  constraints  CS  =  {ci,  ...,cn}  into  independent  subsets 
(denoted  II (CS))  is  defined  as  II (CS)  =  {CS}, ...,  (  'S,„  }  such  that: 
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1.  II  (CS )  partitions  CS. 

2.  Constraints  in  different  partitions  are  independent. 

3.  For  each  partition  containing  more  than  one  constraint,  every  constraint  in 

the  partition  depends  on  some  other  constraint  in  the  partition. 

To  compute  II (CS)  Salsa  uses  a  union-find  algorithm  that  starts  with  each  con¬ 
straint  in  its  own  partition  and  iteratively  merges  partitions  when  they  contain 
dependent  constraints. 

After  partitioning  a  set  of  constraints  into  independent  subsets,  an  integer 
constraint  solver  determines  the  feasibility  of  each  independent  subset.  For  a  set 
of  constraints,  we  may  conclude  that  the  whole  set  is  infeasible  if  any  independent 
subset  is  infeasible. 

Salsa’s  constraint  solver  is  a  decision  procedure  that  determines  whether  a 
set  of  integer  constraints  is  infeasible,  i.e. ,  given  {ci,  Co, ...,  c„}  the  solver  checks 
whether  ci  AcoA...Ac„  is  unsatisfiable.  Note  that  the  c,:  are  terms  from  the  integer 
constraint  fragment  of  SCL  (defined  in  Section  2.1).  Among  several  methods 
available  for  solving  linear  integer  constraints,  one  possible  approach  is  the  use 
of  automata  theoretic  methods.  The  idea,  which  dates  back  to  Biichi  in  the 
early  sixties  [13],  is  to  associate  with  each  constraint  an  automaton  accepting 
the  solutions  of  the  constraint.  The  feasibility  of  a  set  of  constraints  may  then  be 
computed  by  constructing  a  composite  automaton  (from  the  constraint  automata 
for  each  Cj,  1  <  i  <  n)  using  the  standard  construction  for  automata  intersection. 
Salsa’s  solver  employs  the  algorithm  of  Boudet  and  Comon  [12],  extended  to 
handle  negative  number  based  on  ideas  of  Wolper  [34] .  We  give  an  overview  of 
the  algorithm,  for  details  see  the  above  references. 

Let  us  first  examine  how  a  constraint  automaton  may  encode  constraints 
over  the  natural  numbers,  and  then  extend  this  idea  to  automata  for  inte¬ 
ger  constraints.  Let  c  be  a  constraint,  let  Vars(c)  =  {xi ,  x%,  xn},  and  let 
c[yi/xi,  2/2/.T2,  yn/xn]  denote  the  result  of  substituting  yj  for  each  Xj  in  c. 
We  then  define  the  constraint  automaton  for  c,  denoted  CAut(c),  such  that  the 
language  of  CAut(c)  is  {(yi,  G  Intn  \  c[yi/xi,  ...,yn/xn]  is  true}.  Each 

number  yt  is  encoded  in  base  two,  so  each  yt  is  a  string  in  {0, 1}*.  The  constraint 
automaton  will  recognize  solutions  to  a  constraint  by  simultaneously  reading  one 
bit  for  each  of  its  free  variables,  i.e.,  the  edges  of  the  automaton  will  be  labeled 
by  elements  of  {0, 1}™.  For  example,  the  satisfying  assignments  of  LLxi  +  x-2  =  4” 
are  {(0, 4),  (1,  3),  (2,  2),  (3, 1),  (4,  0)},  so  CAut(;ri  +x-2  =  4)  encodes  this  as  shown 
in  Figure  2. 

We  now  explain  how  to  construct  a  constraint  automaton  for  a  constraint  c 
of  the  form  a\X\  +  0-2X2  +  . . .  +  anxn  =  b,  where  a\,  0-2 ,  ■  ■  •  an,  b  are  integer 
constants  and  x\ ,  x-2 ,  ■  •  •  xn  are  variables  over  the  natural  numbers.  The  resulting 
automaton  will  be  of  the  form  CAut(c)  =  ( S,E,St,Acc )  where  S  C  Integers  is 
the  set  of  states  and  E  C  S  x  {0, 1}”  x  S  is  the  set  of  edges,  St  C  S  is  the  set 
of  start  states,  and  Acc  C  S  is  the  set  of  accepting  states.  During  construction 
we  let  Snew  represent  the  set  of  states  still  to  be  processed.  The  construction 
proceeds  backwards  from  the  accepting  state  as  follows. 


1.  Initialize  both  Snew  and  Acc  to  contain  only  b  (the  right  hand  side  of  the  constraint) 

and  initialize  S  =  E  =  St  =  0. 

2.  Remove  a  state  s  from  Snew  for  processing. 

(a)  Add  s  to  S.  If  s  =  0  then  also  add  s  to  St. 

(b)  For  each  0  €  {0,1}"  where  6  =  (bi ,  b2, bn) 
let  6  =  s  —  (aibi  -F  0.262  +  •  •  •  +a„6„)in 

if  S  is  even  then 

•  add  edge  (<5  div  2)  — >  s  to  E 

•  if  (d  div  2)  ^  (5U  Snew)  then  add  (<5  div  2)  to  Snew 

3.  if  Snew  =  0  then  return  ( S ,  E,  St,  Acc)  else  goto  2. 

Some  simple  modifications  to  the  above  algorithm  extend  it  to  handle  nega¬ 
tive  numbers.  For  integer  constraint  c,  the  states  of  CAut(c)  range  over  integers 
and  we  add  a  special  state  T  that  will  encode  the  start  state,  thus  S  C  Int  U I. 
Instead  of  the  standard  binary  encoding  employed  for  natural  numbers  the  two’s 
complement  representation  is  used  for  integers.  The  above  algorithm  must  also 
be  modified  to  handle  the  sign  bit  of  the  two’s  complement  notation  via  a  special 
encoding  for  the  start  state  (I)  and  extra  edges  from  I.  We  do  this  by  removing 
“if  s  =  0  then  also  add  s  to  St”  from  2(a)  and  adding  the  following  to  2(b) 
above. 

if  s  =  (—aibi  —  a2b2  —  ■  ■  ■  -  a„bn) 

then  add  1  to  5  and  St  and  add  edge  I  —>■  s  to  E. 

The  basic  algorithm  may  also  be  changed  to  build  constraint  automata  for 
constraints  involving  and  “<”.  For  “y^”  the  construction  is  exactly  the 
same  except  that  Acc  =  S  —  b,  i.e.,  the  accepting  state  becomes  non-accepting 
and  all  others  become  accepting.  For  details  of  the  slightly  more  complicated 
modifications  for  “<”  see  [10]. 

The  constraint  automaton  for  a  set  of  constraints  CS  =  {ci,ca,  ...,c„},  de¬ 
noted  CAut (CS),  is  defined  as  CAut(CS)  =  f)*;Li  CAut(c,:).  The  automaton 
CAut(C'S')  is  constructed  on  the  fly,  thereby  avoiding  the  need  to  build  each 
CAut(c,;).  Let  Si  denote  the  states  of  CAut(cj),  then  the  states  of  CAut(CS) 
are  Scs  Q  Si  x  S2  x  . . .  x  Sn.  An  unsatisfiability  check  of  CS  then  proceeds 
backwards  from  the  accepting  state  and  terminates  with  false  when  the  initial 
state  is  reached  or  terminates  with  true  if  the  automaton  construction  completes 
without  reaching  the  start  state. 
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5  Empirical  Results 

5.1  Motivation 

Salsa  was  designed  expressly  for  the  problems  of  consistency  checking  and  invari¬ 
ant  checking  SCR  requirements  specifications.  More  specifically,  the  consistency 
checker  of  the  SCR  Toolset  [23]  was  unable  to  carry  out  certain  checks,  such 
as  checks  for  unwanted  nondeterminism  called  disjointness  checks,  especially  on 
specifications  containing  expressions  with  numbers.  We  have  also  been  using 
SPIN  and  SMV,  and  more  recently  TAME  [3],  to  verify  user  formulated  proper¬ 
ties  of  SCR  specifications.  We  compare  Salsa  with  TAME/PVS  to  gain  an  insight 
into  how  well  the  Salsa  approach  performs  in  relation  to  that  of  a  state-of-the-art 
theorem  prover. 

We  compare  Salsa  with  model  checkers  for  the  following  reason.  During  the 
course  of  our  experiments  with  SCR  specifications  we  have  discovered  that  for 
model  checking  to  succeed  on  these  specifications  requires  the  application  of 
abstraction,  which  currently  requires  user-direction  but  is  automatable  [9,22], 
Further,  SPIN  and  SMV  are  unable  to  provide  a  definitive  answer  for  invariant 
checks  on  a  number  of  examples,  especially  when  they  contain  a  large  number  of 
expressions  with  numbers  [27].  Also,  since  several  researchers  are  currently  inves¬ 
tigating  the  use  of  SPIN  and  SMV  for  invariant  checking  software  specifications, 
it  is  our  intention  to  demonstrate  that  Salsa  affords  a  viable,  perhaps  more  auto¬ 
mated  and  cheaper,  alternative  to  model  checking.  Whereas  mechanical  theorem 
provers  are  regarded  as  being  difficult  to  use  and  therefore  restricted  to  sophis¬ 
ticated  users,  model  checking  too  is  often  misrepresented  as  fully  automatic  or 
“push  button” .  Our  intention  is  to  demonstrate  an  approach  to  invariant  check¬ 
ing  that  avoids  both  the  ad  hoc  abstraction  used  in  model  checking  and  the 
sophistication  required  to  apply  mechanical  theorem  proving. 

The  specifications  we  use  in  our  experiments  were  developed  using  the  SCR 
Toolset.  Since  Salsa  seems  to  work  well  on  all  of  this  limited  set  of  examples, 
readers  may  express  skepticism  about  the  generality  of  our  results  -  they  may 
feel  that  there  must  be  benchmarks  for  which  the  roles  would  be  reversed.  By  us¬ 
ing  induction,  abstract  encodings  for  linear  constraints,  and  application-specific 
heuristics,  our  experience  is  that  the  Salsa  approach  can  in  general  be  more 
efficient  than  fixpoint  computation  over  a  finite  domain,  i.e.,  model  checking. 
However,  Salsa  has  the  disadvantage  of  not  working  in  all  cases,  due  to  the 
associated  problem  of  incompleteness. 

Test  Cases.  These  include  a  simplified  specification  of  the  control  software  for  a 
nuclear  power  plant  [24]  (safety-injection),  versions  of  the  bomb-release  com¬ 
ponent  of  the  flight-control  software  of  an  attack  aircraft  [1]  (bomb-release- 1 
and  bomb-release-2),  a  simplified  mode  control  panel  for  the  Boeing  737  au¬ 
topilot  [7]  (autopilot),  a  control  system  for  home  heating  (home-heating), 
an  automobile  cruise  control  system  (cruise-control),  a  navy  application  [27] 
(navy),  the  mode  logic  for  the  Operational  Flight  Program  of  an  attack  aircraft 
[1]  (a7-modes),  and  a  weapons  control  panel  [22]  (wcp). 


10 


5.2  Disjointness  Checking 


To  evaluate  the  performance  of  Salsa,  we  checked  the  above  specifications  for 
disjointness  errors  (unwanted  nondeterminism)  and  compared  the  results  with 
the  consistency  checker  of  the  SCR  Toolset.  The  results  of  our  experiments 
are  shown  in  the  table  of  Figure  3.  No  auxiliary  lemmas  were  used  for 
any  of  the  checks.  The  column  labeled  “number  of  verification  conditions” 
indicates  how  many  invariant  checks  are  required  to  establish  disjointness  for  the 
corresponding  entire  specification.  The  number  of  BDD  variables  is  an  indicator 
of  a  specification’s  size,  and  the  number  of  integer  constraints  correlates  loosely 
with  the  degree  to  which  integers  are  used  in  the  specification.  In  these  tables, 
symbol  “oo  ”  means  that  the  corresponding  system  either  ran  out  of  memory  or 
failed  to  terminate  (over  a  weekend).  The  column  labeled  “number  of  failed  VCs” 
shows  the  number  of  verification  conditions  that  were  not  provable.  Note:  for 
the  specification  a7-modes  Salsa  reports  more  failed  VCs  than  the  SCR  toolset 
because  certain  cases  of  overlap  in  table  entries  are  misdiagnosed  as  disjointness 
errors  when  they  should  probably  be  warnings.  For  specification  cruise-control 
Salsa  establishes  disjointness  in  three  cases  for  which  the  SCR  Toolset  cannot. 
The  tests  were  conducted  on  a  PC  running  Linux  with  a  450  MHz  Pentium  II 
processor  and  256  MBytes  RAM. 


Specification 

Number  of 

Time  (in  seconds) 
to  Check  Disjointness 

Number  of 
Failed  VCs 

Verification 

Conditions 

BDD 

Variables 

Constraints 

SCR 

Toolset 

Salsa 

SCR 

Toolset 

Salsa 

Specifications  containing  mostly  booleans  and  enumerated  types 


safety-inj  ect.ion 

13 

16 

3 

0.5 

0.2 

0 

0 

bomb-release- 1 

12 

34 

9 

0.4 

0.2 

0 

0 

a7-modes 

6171 

158 

3 

145.9 

68.9 

110 

152 

Specifications  containing  mostly  numerical  variables 


home-heating 

98 

112 

55 

oo  t 

4.8 

n.a. 

0 

cruise-control 

123 

114 

75 

21.0 

3.6 

6 

3 

navy 

397 

147 

102 

390.1 

198.2 

0 

0 

bomb-release-2 

339 

319 

230 

oo  t 

246.0 

n.a. 

11 

Fig.  3.  Results  of  Disjointness  Checks 


Figure  3  shows  that  for  specifications  containing  mostly  variables  of  boolean 
and  enumerated  type,  both  the  SCR  Toolset  and  Salsa  can  complete  the  analysis 
but  Salsa  is  somewhat  faster.  For  specifications  containing  mostly  numerical 
variables,  there  were  two  specifications  in  which  Salsa  could  perform  the  analysis 
but  the  SCR  Toolset  could  not. 
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5.3  Checking  Application  Properties 


To  evaluate  Salsa’s  performance  on  properties  formulated  by  users,  we  com¬ 
pared  the  run  times  with  the  theorem  prover  TAME/P  VS  and  the  two  popular 
model  checkers  SPIN  [25]  and  SMV  [28].  (We  used  SPIN  Version  2.9.7  of  April 
18,  1997,  SMV  r2.4  of  December  16,  1994,  and  PVS  version  2.1  for  our  exper¬ 
iments.)  The  results  are  shown  in  Figure  4.  Note  that  the  PVS  proof  times  do 
not  include  time  for  type  checking,  which  can  be  substantial.  We  ran  the  ex¬ 
periments  on  a  SPARC  Ultra-2  running  Solaris  with  a  296  MHz  UltraSparc  II 
processor  and  262  MBytes  RAM.  All  Salsa  proofs  were  completely  automatic, 
but  for  property  304  of  wcp,  which  had  to  be  split  into  two  verification  condi¬ 
tions  for  Salsa  to  complete;  the  time  indicated  with  an  asterisk  is  the  sum  of  the 
running  times  of  the  two  sub-proofs.  All  auxiliary  lemmas  were  automat¬ 
ically  generated  by  the  algorithm  of  [26]  and  proved  as  invariants  by  Salsa. 
Both  SPIN  and  SMV  ran  out  of  memory  (or  ran  indefinitely)  when  run  on  all 
examples  other  than  safety-injection.  This  is  probably  because  they  contain  a 
large  number  of  numerical  variables.  Dashes  (“-”)  in  the  SMV  column  indicate 
that  we  did  not  run  SMV  on  these  examples. 


Specification 

Number  of 
Properties 

Time  (in  seconds) 

Properties 

Proved? 

Auxiliary 
Lemmas  Used? 

|  Salsa\ 

SPIN 

TAME /PVS 

safety-injection 

4 

\  0.8| 

36.0 

155.0 

68 

Yes 

Yes 

bomb-release- 1 

2 

oo  t 

oo  t 

30 

Yes 

No 

autopilot 

2 

oo  t 

oo  t 

82 

Yes 

No 

navy 

7 

396.0 

oo  t 

- 

874 

Yes 

Yes 

wcp 

property  303 

295.4 

oo  t 

- 

oo  t 

No 

No 

property  304 

923.3* 

oo  t 

- 

19 

No 

No 

property  305 

2.4 

oo  t 

- 

8 

No 

No 

Fig.  4.  Results  of  Invariant  Checks 


6  Conclusions 

In  this  paper,  we  show  that  the  Salsa  approach  affords  a  useful  alternative  to 
model  checking,  especially  for  the  analysis  of  descriptions  of  software.  Mechan¬ 
ical  theorem  provers  such  as  PVS  are  regarded  as  being  too  general  and  too 
expensive  to  use,  requiring  sophistication  on  the  part  of  their  users.  Salsa  pro¬ 
vides  the  advantages  of  both  mechanical  theorem  proving  and  model  checking 
-  it  is  automatic,  easy  to  use,  and  provides  counterexamples  along  the  lines  of 
model  checkers.  The  counterexamples,  however,  are  over  two  adjacent  states  and 
not  entire  execution  sequences.  The  main  advantage  of  our  approach  is  that  we 
are  able  to  handle  much  larger  specifications,  even  infinite  state  specifications, 
that  current  day  model  checkers  cannot  handle  (without  a  prior  application  of 
abstraction) . 
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The  major  disadvantage  of  the  Salsa  approach  over  conventional  model  check¬ 
ing  is  its  incompleteness  -  a  proof  failure  does  not  imply  that  the  theorem  does 
not  hold.  However,  this  is  generally  true  of  model  checking  too,  because  an  initial 
application  of  model  checking  to  a  practical  problem  rarely  succeeds  -  users  of 
model  checkers  routinely  apply  abstractions  (mostly  manually  and  sometimes  in 
ad-hoc  ways)  for  model  checking  to  proceed  [9].  These  abstractions  are  usually 
sound,  but  are  often  incomplete  -  consequently,  if  one  model  checks  an  incom¬ 
plete  abstraction  of  a  problem,  the  entire  process  is  incomplete.  Model  checking, 
however,  remains  very  useful  for  refuting  properties,  i.e.,  as  a  debugging  aid. 
As  with  Salsa,  the  resulting  counterexample  must  be  validated  against  the  full 
specification. 

We  plan  to  extend  Salsa  to  include  decision  procedures  for  the  rationals,  the 
congruence  closure  algorithm  to  reason  about  uninterpreted  function  symbols, 
and  special-purpose  theories  such  as  for  arrays  and  lists.  We  would  also  like  to 
reason  about  quantifiers.  We  have  designed  Salsa  to  be  general,  i.e.,  to  check  a 
variety  of  state  machine  models  for  invariant  properties.  We  plan  on  trying  out 
the  tool  on  state  machine  models  other  than  SCR. 
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A  SAL  Specification  of  Safety  Injection  System 

A  module  is  the  unit  of  specification  in  SAL  and  comprises  variable  declarations,  as¬ 
sumptions  and  guarantees,  and  definitions.  The  assumptions  section  typically  includes 
assumptions  about  the  environment  and  previously  proved  invariants  (lemmas).  The  re¬ 
quired  invariants  of  a  module  are  specified  in  the  guarantees  section.  The  definitions 
section  specifies  updates  to  internal  and  controlled  variables.  A  one-state  definition,  of 
the  form  var  x  =  rhs  1  (where  rhs  1  is  a  one-state  SAL  expression),  defines  the  value  of 
variable  x  in  terms  of  the  values  of  other  variables  in  the  same  state.  A  two-state  vari¬ 
able  definition,  of  the  form  var  x  initially  init  :=  rhs2  (where  rhs2  is  a  two-state 
SAL  expression),  requires  the  initial  value  of  x  to  equal  expression  initr,  the  value  of  x 
in  the  “new”  state  of  each  state  transition  is  defined  in  terms  of  the  values  of  variables 
in  the  “new”  state  as  well  as  the  “old”  state.  Expression  @T  (x)  WHEM  y  is  syntactic 
sugar  for  ->x  A  x  A  y  and  @F(x)  denotes  @T(N0T  x).  A  conditional  expression  consists 
of  a  sequence  of  branches  “[]  guard  — >  expression”,  where  the  guards  are  boolean 
expressions,  bracketed  by  the  keywords  “if”  and  “fi”.  In  a  given  state,  the  value  of 
a  guarded  expression  is  equivalent  to  the  expression  on  the  right  hand  side  of  the  ar¬ 
row  whose  associated  guard  is  true.  If  more  than  one  guard  is  true,  the  expression  is 
nondeterministic.  A  conditional  event  expression  (which  is  bracketed  by  the  keywords 
“ev”  and  “ve”)  requires  each  guard  to  denote  an  event,  where  an  event  is  a  two-state 
expression  that  is  true  in  a  pair  of  states  only  if  they  differ  in  the  value  of  at  least  one 
state  variable. 

We  specify  in  SAL  a  simplified  version  of  a  control  system  for  safety  injection  [9]. 
The  system  monitors  water  pressure  and  injects  coolant  into  the  reactor  core  when  the 
pressure  falls  below  a  threshold.  The  system  operator  may  override  safety  injection  by 
pressing  a  “Block”  button  and  may  reset  the  system  by  pressing  a  “Reset”  button. 
To  specify  the  requirements  of  the  control  system,  we  use  variables  WaterPres,  Block, 
and  Reset  to  denote  the  monitored  quantities  and  variable  Safetylnjection  to  denote 
the  controlled  quantity.  The  specification  includes  a  mode  class  Pressure,  an  abstract 
model  of  WaterPres,  which  has  three  modes:  TooLow,  Permitted,  and  High.  It  also 
includes  a  term  Overridden  and  several  conditions  and  events. 
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module  sis 
functions 

Low  =  900;  Permit  =  1000; 
monitored  variables 

Block,  Reset  :  {On,  Off}; 

WaterPres  :  int  in  [0,2000]; 
controlled  variables 

Safetylnjection  :  {On,  Off}; 
internal  variables 
Overridden  :  bool; 

Pressure  :  {TooLow,  Permitted,  High}; 
assumptions 

/*  Mode  invariant  generated  by  the  algorithm  of  Jeffords  [26]  */ 

LemmaZ  =  (Overridden  =>  Reset  =  Off  and  not  (Pressure  =  High)); 
guarantees 

/*  The  following  properties  are  true  */ 

Propertyl  =  (Reset  =  On  and  Pressure  !=  High)  =>  not  Overridden; 
Property2  =  (Reset  =  On  and  Pressure  =  TooLow)  =>  Safetylnjection  =  On; 
/*  The  following  properties  are  false  */ 

Property3  =  (Block  =  Off  and  Pressure  =  TooLow)  =>  Safetylnjection  =  On; 
Property4  =  (@T(Pressure=TooLow)  when  Block=0ff)  =>  SafetyInjection’=0n; 

definitions 

var  Overridden  initially  false  := 
ev 

[]  @T  (Pressure  =  High)  ->  false 

[]  @T (Block  =  On)  when  (Reset  =  Off  and  Pressure  !=  High)  ->  true 
[]  <§T  (Pressure  !=  High)  or 

@T (Reset  =  On)  when  (Pressure  !=  High)  ->  false 
ve 

var  Pressure  initially  TooLow  := 
case  Pressure 


[] 

TooLow  -> 

ev 

[] 

QT (WaterPres 

>=  Low)  ->  Permitted  ve 

[] 

Permitted 

->  ev 

[] 

@T (WaterPres 

<  Low)  ->  TooLow 

ve 

ev 

[] 

@T (WaterPres 

>=  Permit)  ->  High 

[] 

High  -> 

[] 

@T (WaterPres 

<  Permit)  ->  Permitted  ve 

esac 

var  Safetylnjection  = 
case  Pressure 

[]  High,  Permitted  ->  if  []  true  ->  Off  []  false  ->  On  fi 
[]  TooLow  ->  if  []  Overridden  ->  Off  []  not  Overridden  ->  On  fi 
esac 

end  module 


Fig.  5.  SAL  specification  of  Safety  Injection  System 
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